UPnP is a framework, developed in a multi-vendor collaboration called the UPnP Forum. UPnP Forum establishes standardised device protocols, specifying a plurality of format standards and communication protocols which enables different IP devices to interact in a local network in order to perform certain tasks, such as e.g. rendering of media content, using different access technologies, operating systems, and programming languages. More details on these issues can be found in “UPnP AV architecture version 1.0”, Jun. 22, 2002.
A simplified UPnP Audio/Video (AV) architecture, which enables a user to control a play out of digital media content in a UPnP network, according to the prior art, will now be schematically described with reference to FIG. 1.
FIG. 1 illustrates an exemplary content playback scenario, involving three distinct UPnP components, namely a Media Server (MS) 100, a Rendering Device, or a Media Renderer (MR) 110, and a Control Point (CP) 120, adapted for a UPnP network. These three components, each having a well-defined role in the described content playback scenario, interact in order to accomplish specific tasks, initiated from, and under supervision of, the CP 120. In the present scenario, MS 100, which may be e.g. a VCR, a CD/DVD player/jukebox, a camera, a camcorder, a PC, a set-top box (STB), a satellite receiver, or a audio tape player, contains content that a user wants to render, e.g. display and/or listen to, on a suitable MR, i.e. a device adapted to present content retrieved from MS 100, In this case MR 110. The MR 110 may be any of a TV, a HI-FI equipment, network-enabled speakers, an MP3 player, Electronic Picture Frames (EPF), a music controlled water fountain, or any other device, suitable for presentation of content in an appropriate form.
A user interacts with an application logic, or a UI application, of the CP 120 via a User Interface (UI) 121, which may be integrated with the CP 120, or configured as a separate UI, adapted to interact with CP 120. UI 121 enables the user to locate and select a desired content on MS 100, and to select an appropriate target MR 110, on which the user wants the selected content to be rendered. CP 120, which may be e.g. a TV, typically comprising a traditional remote control, a PC, a LapTop, a cellular telephone, or a wireless PDA-like device provided with a display, communicates with MS 100 and MR 110 via a Local Area Network (LAN) 130, via commands, typically standard UPnP actions, entered by the user.
MS 100 contains, or has access to, content, typically different categories of entertainment content, that is stored, either locally 101 on the MS 100, or on an external storage device 102 that is accessible from MS 100. MS 100 is able to access its content, and to transmit it to a rendering device via another network 140, operating in accordance with some type of Out-of-Band transfer protocol and a data format that is understood both by the MS 100 and the MR 110. Such a media content delivery is typically provided by executing Isochronous or Asynchronous Push or Pull.
The content exposed by MS 100 may include arbitrary types of content, including e.g. video, audio, and/or still images. MS 100 may be configured to support one or more transfer protocols and data formats for each content item. Alternatively it may be adapted to convert the format of a given content item to be delivered into another suitable format on the fly.
The type of content that a MR can receive depends on which transfer protocols that are used and on the data formats that the MR supports. Some MRs may only support a single type of content, such as e.g. video audio or still images, whereas other MRs may have been adapted to support a wide variety of different content types.
CP 120 coordinates and manages the operation of MS 100 and MR 110, as directed by a user, e.g. via commands or actions, which may be used by a user to enter or initiate typical UPnP activities, such as e.g. play, stop, pause etc., to be executed by the CP 120 for the purpose of accomplishing a desired task, e.g. to retrieve “MyFavorite” music from MS 100, and to play the retrieved music on a suitable MR, such as MR 110.
As indicated above, CP 120 typically provides a UI 121, enabling the user to control the operation of one or more available MSs, and one or more available MRs, e.g. in order to select and render desired media content. The layout of the CP's UI 121, and the functionality that it exposes, will typically be implementation dependent and, thus, determined by the manufacturer of the CP 120. According to the present UPnP standards, CP 120 allows users to use different service types (103;111) to be able to control the selected MS and MR, respectively. Service type “ContentDirectory” (CDS) enables the CP to browsers and search for content objects stored at a MS, while the service type “RenderingControl” (RCS) enables the CP to control an initiated rendering procedure, such as e.g. the volume level, when playing out content retrieved from a MS on a MR. Service type “ConnectionManager” (CM) is another service type which the CP may use towards both a MS and a MR in order to set up a connection between the CP and the respective other entity. The AVTransport (AVT) Service is another service type used by the CP 120 to control the playback of content that is associated with a specific AVTransport. This service type includes the ability to activate activities, such as e.g. Play, Stop, Pause, Seek, etc., via specific commands, depending on the supported transfer protocols and/or the data formats used. This service type defines a common model for A/V transport control, suitable for the generic user interface, i.e. UI 121. The main functionality of this service type is to gain control over the so-called “TransportState” variable of the MS.
An exemplary state machine for a MS, according to the prior art, will now be described with reference to FIG. 2, depicting different possible states (214-220) and commands or UPnP actions (201-212), which, when entered or initiated by a user, initiates an activity on the MS, and, as a consequence, a variable transition from one state to another state in the state machine. FIG. 2 specifically illustrates states, UPnP actions and variable transitions, for the “TransportState” variable. The Play( ) action 201, may for example initiate a TransportState variable transition from the state “STOPPED” 218 to the state “PLAYING” 220. In a scenario where content is being played out from a MR, the playback initiated by the Play( ) action may later be paused by the CP, transmitting the “Pause( )” action, 210 to the selected MS. The Pause( ) action 210 causes the TransportState variable to change from “PLAYING” state, 220, to “PAUSED PLAYBACK” state, 214. By later transmitting Play( ) action, 202, to the MS, the CP will be able to instruct MS to resume the play out, and, thus, the TransportState variable will again return to the “PLAYING” state 220.
In order to provide for a transfer of content between a MS and a MR, a signalling procedure between a CP, controlling the transfer, and the respective MS and MR, executed via network 130 of FIG. 1, will be necessary. A content playback scenario, as defined by the Asynchronous-pull transfer protocol in UPnP AV version 1.0, according to the prior art, will therefore now be described with reference to the signalling diagram of FIG. 3.
In FIG. 3, a transfer protocol, such as e.g. HyperText Transfer Protocol (HTTP), is used for obtaining a transfer of media content between a MS 100 and a MR 110. In this case, MR 110 performs a HTTP GET action on a URL, pointing to a content file of MS 100, as provided by CP 120.
In a first step 3:1, a user searches for content to render, e.g. by browsing the content of MS 100, typically by initiating the CDS service type, via a UI (not shown) of CP 120. In a next step 3:2, the user obtains protocol and format information in a Protocol/Format List retrieved from MR 110, using service type CM. In a subsequent step 3:3, CP 120 chooses a matching protocol and format, preparing for a future content transfer. In a next step 3:4 and a subsequent step 3:5, CP 120 uses service type CM to prepare for a connection with MS 100 and MR 110, respectively, according to the UPnP standards. In a step 3:6, CP 120 provides the URL, necessary for obtaining the required content, to MR 110, using a AVT service type, and in a subsequent step 3:7, an action, in this case the UPnP Play( ) action, is initiated from CP 120 by the user, typically via HTTP get, or in a RTSP play request.
In another step 3:8, a transport protocol is invoked, and a content file, pointed to by the retrieved URL, is transferred from MS 100 to MR 110 via a conventional Out-of-Band content transfer. In a next step 3:9, the user controls the rendering of the content from CP 120, in this case by controlling the volume, using the RCS service “SetVolume” action. In a subsequent step 3:10 the content transfer is completed, and if necessary, the procedure may be repeated, as indicated with another step 3:11.
There are mainly two critical point in the presented AV session setup. Initially, an error may occur in association with, or subsequent to, MR 110 having initiated a request for playing out the selected content from the MS 100, i.e. a Play( ) action may not have been executed correctly. Such an occasion is indicated as “1” in the figure. Secondly, an error may occur in association with the required transfer of the content, as indicated with “2” in the figure. Such an error may result in corrupt content being delivered to MR 110, or even in no transfer at all to the MR.
If the MS from which content is to be retrieved is located at a remote distance from the MR, on which the content is to be rendered, an alternative architecture, adapted for handling remote interaction between the respective entities will be necessary. Such an architecture, according to the prior art, will now be described with reference to FIG. 4.
FIG. 4 schematically describes an architecture suitable for the support of an IP Multimedia Subsystem (IMS) assisted UPnP Remote Access (RA) connection set up, which may be performed in order to handle media transfer of content between two remotely located UPnP networks. The present scenario may be defined as follows: It is close to Christmas and a son living abroad wants to share some pictures with his parents. At the same time he also wants to wish his parents a Merry Christmas and a Happy New Year. It is assumed that the son is at his home 400 abroad and that his parents presently are at their home 410, both homes having a respective local UPnP network, 401 and 411, installed. Each UPnP network 401, 411 comprises a respective Home IMS Gateway (HIGA) 402 and 412, each of which is implemented at a respective Residential Gateway (RGw) (not shown). A HIGA is a multimedia gateway that can generally emulate an IMS terminal from the local UPnP network towards an IMS network, in order to access IMS services on behalf of a device located in the local network. FIG. 4 illustrates some basic steps 4:1-4:3, which will be executed during a connection setup for an IMS assisted UPnP remote access, according to the prior art.
In a first initial step 4:1, an IMS authentication and authorization procedure of the son's HIGA 402 is performed at the parent's HIGA 412, via an IMS network 420, here represented by network node 421. In a next step 4:2, a Virtual Private Network (VPN) set-up is performed between the two HIGAs 402 and 412, in order to provide for a secure transfer of content between the two local networks. Once the two initial steps have been successfully performed, a Digital Living Network Alliance (DLNA) media delivery may be executed from a MS 100, located at the home 400 of the son, to a MR 110, located in the parents home network 411, via the VPN connection. This is indicated with a step 4:3. MR 110 may be e.g. a TV/STB, a Picture Frame through a laptop, or a mobile device, which is adapted to act as a WIFI SIP/DLNA client behind HIGA 412.
A UPnP CP 120, typically controlled by a user via a UPnP remote access client 403, make up the requesting end point at the son's home network 401. The UPnP CP/UPnP remote access client 403 could reside either in a fixed Customer Premises Equipment (CPE) device, e.g. a HIGA in a RGw, in a mobile terminal, or be distributed between a mobile device 403 and a RGw 120, as shown in FIG. 4.
In a scenario, where the CP and the MR involved in a content transfer are located close to each other, the user that has activated an action via the CP will in most cases easily be able to inspect the MR visually during the complete transfer process, and, thus, the user will thereby also be able to verify that an initiated transferring procedure is executed as expected, or if that is not the case, the user usually will be aware of that, and, thus, he will also be able to make a decision to make another try or to start to identify the reason for the unsuccessful attempt, without any further delay.
However, in a scenario where a UPnP CP requests a media asset, such as e.g. a video stream or a picture, to be played on a MR, e.g. a media player, residing at a remote location, e.g. as described in the previous example, the user that initiated the content delivery will be unaware of whether the media asset has successfully started playing at the remotely located media player, or if some problem with the play out has occurred in the remote media player sometimes during the delivery of the content.